this won't work as already mentioned in pi-apps discord

Steam self-updates but I am fairly sure it does not reinstall its own deb, so this should be fine long-term unless I am missing something.

installation of the steam deb adds the steam apt repo. they use a less known trick that if you put arch= in the debian sources list the Packages file for that architecture will always be downloaded to your system by apt, not just the dpkg architecture and foreign architecture of your system. Now the dpkg supported architecture rules still apply so you can't simply install amd64 and i386 packages from those repos, but the steam-launcher package is Architecture: all (that is what the package name of the steam.deb is). It gets frequently updated the and last update was Date: Mon, 12 Feb 2024 20:07:16 UTC

For this reason, modifying the deb the first time won't work. Also, modifying the deb to not include the apt repo won't work either as that would prevent steam from updating the files managed by the debian package which will lead to breaking steam at some point in the future

It seems less hacky than detecting the preferred terminal beforehand and then changing it back to whatever the default was before.

also, this should not be necessary in the first place. it is a debian (or really piOS since they are the DE curator) bug that lxterminal has such a low priority

debian/ubuntu postinst for xterm (the package) set xterm (the binary) to priority 20 and lxterm (the binary) to priority 30

#!/bin/sh
set -e
# Automatically added by dh_installalternatives/13.11.4
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = "abort-deconfigure" ] || [ "$1" = "abort-remove" ]; then
        update-alternatives --install /usr/bin/x-terminal-emulator x-terminal-emulator /usr/bin/xterm 20 \
            --slave /usr/share/man/man1/x-terminal-emulator.1.gz x-terminal-emulator.1.gz /usr/share/man/man1/xterm.1.gz
fi
# End automatically added section
# Automatically added by dh_installalternatives/13.11.4
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = "abort-deconfigure" ] || [ "$1" = "abort-remove" ]; then
        update-alternatives --install /usr/bin/x-terminal-emulator x-terminal-emulator /usr/bin/uxterm 20 \
            --slave /usr/share/man/man1/x-terminal-emulator.1.gz x-terminal-emulator.1.gz /usr/share/man/man1/uxterm.1.gz
fi
# End automatically added section
# Automatically added by dh_installalternatives/13.11.4
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = "abort-deconfigure" ] || [ "$1" = "abort-remove" ]; then
        update-alternatives --install /usr/bin/x-terminal-emulator x-terminal-emulator /usr/bin/koi8rxterm 20 \
            --slave /usr/share/man/man1/x-terminal-emulator.1.gz x-terminal-emulator.1.gz /usr/share/man/man1/koi8rxterm.1.gz
fi
# End automatically added section
# Automatically added by dh_installalternatives/13.11.4
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = "abort-deconfigure" ] || [ "$1" = "abort-remove" ]; then
        update-alternatives --install /usr/bin/x-terminal-emulator x-terminal-emulator /usr/bin/lxterm 30 \
            --slave /usr/share/man/man1/x-terminal-emulator.1.gz x-terminal-emulator.1.gz /usr/share/man/man1/lxterm.1.gz
fi
# End automatically added section

debian/ubuntu lxterminal (the package) set lxterminal (the binary) to priority 20

	configure)
		update-alternatives --install /usr/bin/x-terminal-emulator \
			x-terminal-emulator /usr/bin/lxterminal 20 \
			--slave /usr/share/man/man1/x-terminal-emulator.1.gz \
			x-terminal-emulator.1.gz /usr/share/man/man1/lxterminal.1.gz
		;;

that is a bug. in no case should lxterminal not have a higher priority than lxterm/xterm.
definitely not when LXDE or piOS wayfire are used as the DE.

Also, modifying the deb to not include the apt repo won't work either as that would prevent steam from updating the files managed by the debian package which will lead to breaking steam at some point in the future

After your reply on the discord this was my first thought.
For a while now I have actually wanted to investigate removing steam's repo and making pi-apps handle steam deb reinstalls. That would notify us of updates and allow us time to issue a temporary downgrade if box64 needs a fix.

The full steam package archive is here: https://repo.steampowered.com/steam/archive/stable/
Seems to me like downloading a specific deb version would be fine, and as long as the github bot updates the version on the same day that steam releases a new version, that should be fine. Am I missing something? If not I'll add those changes to this PR.

After your reply on the discord this was my first thought. For a while now I have actually wanted to investigate removing steam's repo and making pi-apps handle steam deb reinstalls. That would notify us of updates and allow us time to issue a temporary downgrade if box64 needs a fix.

unfortunately that can't be done. steam, as you know, updates its non-root owned files on its own (the ones in the users home directory). that is where the main install lives and you can't downgrade it. the steam deb only provides some launcher scripts and that ubuntu minimal bootstrap tarfile (some binaries that steam depends on)

Possible bugfix advantages aside, as long as pi-apps keeps the deb updated relatively quickly, should all be fine?

Possible bugfix advantages aside, as long as pi-apps keeps the deb updated relatively quickly, should all be fine?

I just don't see this as a good idea and it leads to just one more point of failure. I think you are looking at the wrong place to fix the issue. This is an issue upstream in two places.

First: steam should remove its dependence on xterm and use a generic x-terminal-emulator. The steam startup script requires it. So we actually should not remove it.

                xterm -T "$title" -e "cat $tmpfile; echo -n 'Press enter to continue: '; read input"

Second: piOS (and possibly debian itself) should change the priority of lxterminal to be higher.

Possible bugfix advantages aside, as long as pi-apps keeps the deb updated relatively quickly, should all be fine?

I just don't see this as a good idea and it leads to just one more point of failure. I think you are looking at the wrong place to fix the issue. This is an issue upstream in two places.

Try to look at my latest commit with an open mind. This seems actually much simpler and avoids the need for a reboot as we are editing files in-place.

First: steam should remove its dependence on xterm and use a generic x-terminal-emulator. The steam startup script requires it. So we actually should not remove it.

                xterm -T "$title" -e "cat $tmpfile; echo -n 'Press enter to continue: '; read input"

Right now the default control file requires either xterm or gnome-terminal or konsole, so I am surprised that bin_steam just blatantly runs xterm. That would fail on any system where gnome-terminal or konsole were already installed.
But there is a reason this has never been noticed and fixed: that xterm line is a fallback in case zenity fails to display a message. So this issue is bigger than us, and also is a non-issue.

The only other place I see xterm mentioned is in /usr/lib/steam/bin_steamdeps.py.
And you can see here that it actually does have a case for x-terminal-emulator.

programs = [
            ("konsole",
             ["konsole", "--nofork", "-p", "tabtitle=" + title, "-e"]),
            ("xterm",
             ["xterm", "-bg", "#383635", "-fg", "#d1cfcd", "-T", title, "-e"]),
            ("x-terminal-emulator",
             ["x-terminal-emulator", "-T", title, "-e"]),
            # If we reach this point either 'gnome-terminal' is not available
            # or the current version is too old for the new '--wait' option.
            # Anyway we can't know for sure if '--disable-factory' option
            # is supported until we try it because, for example,
            # on Ubuntu 16.04 '--disable-factory' is available but it doesn't
            # show up with '--help'. Leave this 'gnome-terminal' test as the
            # last resort because it's highly likely to fail.
            ("gnome-terminal",
             ["gnome-terminal", "--disable-factory", "-t", title, "--"]),
        ]

To me it looks like in all cases except the one where zenity fails to launch, steam will function flawlessly on a system with only x-terminal-emulator installed.

So now we could ask nicely and wait for Steam or PiOS to fix it, but that is only a good choice in a perfect world. Pi-Apps has no place in a perfect world. Its whole purpose is to make apps available on a platform that apps' devs did not bother to support properly.
Pi-Apps is one big workaround - something that should ideally not need to exist, but does.

I just don't see this as a good idea and it leads to just one more point of failure. I think you are looking at the wrong place to fix the issue. This is an issue upstream in two places.

Try to look at my latest commit with an open mind.

please notify upstream and attempt to have the problems fixed. downstream workarounds only cause more issues in the long run.

This seems actually much simpler and avoids the need for a reboot as we are editing files in-place.

A reboot is only necessary in the case when there are no existing /usr/local/bin and /usr/local/share/applications folders at the time of login (when the daemons get started that look for binary and application .desktop file). In most cases it isn't necessary.

Right now the default control file requires either xterm or gnome-terminal or konsole, so I am surprised that bin_steam just blatantly runs xterm. That would fail on any system where gnome-terminal or konsole were already installed. But there is a reason this has never been noticed and fixed: that xterm line is a fallback in case zenity fails to display a message. So this issue is bigger than us, and also is a non-issue.

I don't think this is the only case where xterm is hardcoded. I see another in ~/.local/share/Steam/steam.sh for a similar reason as the one you described. I know I have personally seen xterm show on my desktop linux computers with steam (with another terminal as default) so it is probably still used elsewhere that we are not checking. (note: I wrote this before your above post)

Also, regarding e7b8e36 , rewriting the steam deb is not necessary to take over /usr/bin/steam. Take a look at dpkg-divert. I make extensive use of this tool in Switchroot Ubuntu (in debian package postinst scripts but ofc you can run it from cli as well) to divert files owned by other packages so that I can provide my own.

One thing that you are failing to take account as well is the users that install something and then do not (or rarely) update from pi-apps. They expect that things continue to function without interation and "not updating" just means they will not get new features or fixes. If pi-apps takes over updating the steam debian managed files then for these users it will break unexpectedly.

So now we could ask nicely and wait for Steam or PiOS to fix it, but that is only a good choice in a perfect world.

There is a difference between notifying upstream, waiting for a response, and if the response is not satisfactory then implementing something yourself and implementing something yourself immediately. Issues like this go unnoticed and unfixed because they are never reported.

If upstream is unwilling to implement a proper fix promptly, I think the issue would be best resolved by solving the root issue which is the priority of lxterminal. Simply detect the current users DE and if LXDE/piOS-wayfire then add a priority for lxterminal at a more sensible higher priority. If lxterminal gets a package update that will be overwritten but I think its OK since lxterminal has literally not had a package update in years -- Andrew Lee (李健秋) <[email protected]> Tue, 21 Dec 2021 21:49:58 +0800

Possible bugfix advantages aside

As explained, I don't forsee any bugfix advantages. We cannot control the ~/.local/share/Steam folder. it force updates to latest regardless of what you do. All this is doing is desyncing the steam debian package from valves control and placing the burden of handling it on us (which I personally want no part of)

One thing that you are failing to take account as well is the users that install something and then do not (or rarely) update from pi-apps. They expect that things continue to function without interation and "not updating" just means they will not get new features or fixes. If pi-apps takes over updating the steam debian managed files then for these users it will break unexpectedly.

Good point. But could the same logic be applied to apt upgrades?

• If pi-apps manages steam deb updates, then users need to update pi-apps
• If apt manages steam deb updates, then users need to do an apt upgrade

I would imagine that users would either do both, or neither one.